CICDを体験できる「Modern CI/CD with GitHub and AWS CodePipeline」に参加しました #AWSreInvent
2024.12.03re:Invent 2024 において、GitHubとCodePipelineを使用したCICDを体験できるワークショップ「Modern CI/CD with GitHub and AWS CodePipeline」に参加してきました。
概要
タイトル：Modern CI/CD with GitHub and AWS CodePipeline
Level: 300 – Advanced
Speaker：Robert Bradley,Matt Laver
概要：※下記は機械翻訳
このワークショップでは、GitHubとAWS CodePipelineを使った継続的インテグレーションと継続的デリバリー(CI/CD)のパイプラインをAWS Management Consoleを通して構築する方法を学びます。 モノレポとブランチ戦略の扱い方を学びます。 自動ロールバック、パイプライン・パラメーター、ステージ・レベル条件、同時実行モードなど、パイプラインのパフォーマンスを向上させる高度な機能を探求します。 参加にはラップトップが必要です。
体験できたことまとめ
- AWSアカウントをGitHubに安全に接続する方法
- インフラストラクチャコード用のCICDパイプラインの構築方法
- アプリケーションコード用のCICDパイプラインの構築方法
- GitHub Flowを使用して新しい機能を作成して、ビルドををトリガーする方法
- 自動ロールバック戦略の実装方法(時間内に間に合いませんでした...)
アーキテクチャ
使用したAWSサービス
- CodePipeline：リリースパイプラインの自動化サービス
- CodeBuild：ソースコードのコンパイルやテスト、イメージのビルドなどを自動化
- ECR：コンテナレジストリサービス
- App Runner：ネットワークやサーバーなどのインフラ部分を丸ごとマネージドしてくれるサービス、Webアプリサーバーとして利用
- DynamoDB：データベース層として利用、サーバーレスなNoSQLが特徴
学んだこと
モノレポの利点について
モノレポ（モノリシック リポジトリ」）は、各プロジェクトまたはコンポーネントを個別のリポジトリに分割するマルチレポアプローチではなく、フロントエンド要素やバックエンド要素などの複数のプロジェクトまたはコンポーネントのコードを単一の統合リポジトリに保存するソフトウエア開発戦略です。
- 複数のプロジェクトにて同様のライブラリを使用していたり、ツール(リンターやフォーマッター等)を使用している場合、モノレポにすることでそれらの管理が容易となり、結果的にコードの品質を均一にしやすいメリットが生じます。
- 1つのリポジトリにソースが全て存在することで、まとまってバージョン管理することができます。つまり単一のリポジトリを確認すれば過去の変更を全て追うことができます。
要はソースコードを管理するリポジトリが1つにまとまっていることで、バージョンやライブラリ、ツールの管理が容易になるということです。
これらはプロジェクトの規模や特性に合わせてモノレポとマルチレポの使い分けをするといいでしょう。
ブランチ戦略について
- ブランチ戦略の目標
- 本番コードベースに影響を与えず、独立して機能や修正に取り組める
- 複数のメンバーの作業のスムーズな統合
- レビューや自動テストによる品質保証
- 製品の複数のバージョン管理(検証や本番環境など)
- 戦略の代表的な種類
- GitHub Flow：メインブランチを中心として、すべての新機能、修正、改善は、プルリクエストを通じてメインブランチに統合する手法
- CI/CDによるペースの速い開発に重点を置いたチームに適している
- トランクベースの開発：頻繁に小さい変更をメインブランチにマージする手法
- スタートアップなどCI/CDと頻繁なリリースを実践しているチームに適している
- リリースブランチ：リリースバージョンごとに個別のブランチを作成する手法
- 複数の製品バージョン（エンタープライズソフトウェアなど）を管理するチームに適している
- フォークワークフロー：メインリポジトリをフォークし、プルリクエストを送信する手法
- アクセスが制限されているオープンソースプロジェクトまたは大規模なチームに適している
- GitHub Flow：メインブランチを中心として、すべての新機能、修正、改善は、プルリクエストを通じてメインブランチに統合する手法
私が馴染みがあるのはGitHub Flowで、シンプルな戦略故に運用が破綻しにくいので好きです。
今回のワークショップでもGitHub Flowを使用しましたが、複数人が並行作業で開発する場合はmainブランチへのマージが頻発しコンフリクトが発生しやすくなるデメリットを意識されました。
改めてプロジェクトに沿ったブランチ戦略を選択できるようになりたいなと感じました。
CICDについて
- CI/CDとは
- 継続的インテグレーション(CI)とは、開発者によるコードの変更を共有リポジトリに自動的に統合する手法。新しいコードがリポジトリにマージされるとすぐに、自動ビルドおよびテストプロセスが開始され、コードベースが安定して機能し続けることが保証される。
- 継続的デリバリー(CD)とは、継続的インテグレーションの次のステップで、統合およびテストされたコードが常に本番環境にリリースできる状態になります。継続的デリバリーでは、すべての変更が自動テストに合格した後、ステージング環境または本番前環境に目動的にデプロイされる。コードを本番環境にプッシュするかは手動で行われる。
- 継続的デプロイメント(CD)とは、継続的デリバリーと異なり本番環境に自動的にデプロイされる。
- CICDの各ステージ
- 1.計画：チームが構築する必要がある機能や更新を定義する最初の段階。開発の優先順位と目標を決定する。
- 2.コード：コードの変更をリポジトリにプッシュする。CI/CDではエラーを早期に検出するために、小規模・頻繁なコミットを推奨。
- 3.ビルド：コンパイル、エラーチェック、テスト用アプリケーションの準備。正しくアプリケーションが実行できることを保証。
- 4.継続的テスト：コードの正確性を検証するために自動テスト(ユニットテスト、統合テスト、エンドツーエンドテスト等)を実行し、新しいコードが既存の機能と適切に統合され、品質基準を満たしているかどうかを検証。
- 5.リリース：すべてのテストに合格した後、リリースステージにて展開の準備が整う。リリースはステージング環境に自動的に送信されるか、本番環境への最終承認を待つ展開可能な状態のままになる。
- 6.デプロイ：テストされ承認されたコードが本番環境にプッシュ。手動承認もしくは完全に自動化。
- 7.運用：アプリケーションが監視され、期待どおりに動作するかどうかを確認。問題が検出された場合はロールバックかパッチを適用してユーザーへの悪影響を抑える。
- 8.監視：アプリケーションの健全性とパフォーマンスを追跡するために監視を行い、稼働時間、応答時間、ユーザーの行動に関するデータを収集する。
CICDによってコードの変更に対して素早く問題の検知やデプロイを行えるようになることで、効率良く市場に適したアプリケーションを展開することができるようになり、ビジネスサイクルが早まる現代にとって必要な技術であることがわかります。
まとめ
ワークショップ自体は、GithubをソースにCodePipeline(CodeBuild)でひたすらアプリやインフラのCICDを作成すると言う内容で、個人的には目新しい内容ではなく復習の意味合いが強いワークショップとなりました。
特にモノレポとブランチ戦略についての比較はよく忘れてしまうこと、また最近はCICDにGitHub Actionsを使う機会が多くCodeシリーズの復習としては非常に良かったです。
2時間枠では最後まで辿り着かず、最後のロールバック周りに触れなかったのが悲しかったです。
次回のワークショップからは初めて全てのページを保存しておこうと強く思ったのでした。
![[小ネタ] CodePipeline で ECS のデプロイを行う場合の選択肢と構築後の見分け方について](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-7cdd08196c0c75239e41fd834b427547/b64ab4252df175f1536fe199afbab2a3/aws-codepipeline)
